feat(memory): encrypt local store and preserve reviewed Markdown portability - #347

Summary

Extend the encrypted-memory follow-up to the existing memory stack. Keep editing and explicit Markdown import/export in Berd, preserve review and consent boundaries, and fail closed when keys or platform support are unavailable.

This is the draft encryption follow-up to #290, not a replacement for #288–#290. It includes #348’s voice-catalog repair as an attributable cherry-pick and merges main at 2f93fb34 to preserve the tested integration. Clay’s branches are unchanged. Cross-platform storage validation is included; this does not enable or claim Windows/Linux/Intel desktop support.

• Encrypt active documents, pending proposals, approval/suppression metadata, and transaction journals with authenticated AES-256-GCM. Keep keys in the platform keystore, never in renderer responses, subprocess arguments, environment variables, or plaintext store files.
• Keep memory-off available while key authorization is pending. Key access does not hold the transaction/policy lock; initialization remains separately serialized. Revalidate store identity and markers before recovery/publication. Run blocking app operations on bounded workers without treating async cancellation as cancellation of a native key request.
• Enforce the current Apple-silicon macOS availability boundary across native commands, frontend reads/polling, agent context, managed MCP registration, and packaging. Unsupported builds preserve existing data and cannot reactivate managed memory from stale settings.
• Add opt-in portable-store validation for the shared store/MCP on Intel macOS, Linux, and Windows. Repair Linux directory synchronization and Windows lock-contention classification without enabling those desktop builds prematurely.
• Deliver repeated memory-off transitions correctly to external harnesses, including after memory was re-enabled.
• Add synthetic regression coverage, a local portability runner, and a read-only signed-artifact inspection helper. Metadata inspection is not keystore acceptance.

Related issue

Depends on the existing draft stack:

• feat(memory): add secure user-owned memory store #288 — memory foundation
• feat(memory): require review for memory proposals #289 — reviewed proposals
• feat(memory): connect agents through memory MCP #290 — memory MCP
• feat(memory): encrypt local store and preserve reviewed Markdown portability #347 — this encryption follow-up
• fix(i18n): restore voice settings strings on the memory stack #348 — voice-catalog repair included here as a separate signed cherry-pick; propagation into the lower stack remains with its owner

No separate issue was found in the scoped memory encryption issue search. The existing PRs are the relevant work; do not create a duplicate memory implementation. Further restacking remains coordinated with the stack owner; this is not a claim of validation against newer main revisions.

Testing

Completed on the integrated implementation snapshot (all executable source/config/test inputs match this PR; four subsequent documentation updates reconcile status):

Data tests use synthetic temporary stores and injected keys. Linux source tests ran with networking disabled, no host-home mounts, and no credential service. Windows cross-compilation is not Windows execution. Rosetta is not final Intel-hardware/package acceptance.

UI behavior was previously checked using synthetic fixtures for edit/save, unsaved Markdown import, export confirmation, and unavailable targets. Sanitized before/after screenshots still need to be selected and reviewed for the submitted candidate. No screenshots of real memory are required or appropriate.

Behavior and compatibility

• LAWS/MEMORY.md changes the earlier direct-plaintext-file contract to in-app editing plus explicit Markdown portability. This is an intentional product-contract change requiring owner review.
• Legacy non-fresh stores are refused and preserved; no automatic migration, reset, recovery key, or machine-transfer flow is implemented.
• Missing established keys never silently regenerate. Key loss can make ciphertext unrecoverable.
• Filenames, sizes, and policy state remain visible. Explicit exports, previous backups, recalled text in agent transcripts, and compromised/same-user process access are outside the at-rest protection claim.
• Complete authenticated snapshot rollback is not detected. Older plaintext binaries can damage the same store. These limitations require explicit rollout decisions.
• Windows atomic file publication is not a claim of Unix-equivalent directory-flush power-loss durability.

Why this remains draft

• Verify actual signed Mac app/sidecar key authorization through initialization, pending/denied prompts, relaunch, and update in an isolated account. Do not use the publishing release workflow merely to obtain a test artifact.
• Verify CI on this updated PR head. Full local just ci passed, and branch reconstruction matched the tested source before the documentation-only update. Further stack/base changes need applicable revalidation.
• Agree on legacy-data handling, old-binary/downgrade behavior, and recovery/rollback scope with the feature owners.
• Close the existing feat(memory): connect agents through memory MCP #290 sidecar-resolution review requirement with its owner. Import hardening is separate and does not close that finding.
• Native Windows/MSVC execution, real Credential Manager/Secret Service lifecycle behavior, and cross-platform desktop registration/UI/package integration remain follow-up acceptance work before opening those platform gates.

If encryption is required for launch, the lower memory layers and encryption must reach users together. Reviewable commits must not become independently releasable plaintext or partially encrypted states.

AI tools assisted with implementation and tests. The submitting contributor remains responsible for reviewing the code, evidence, and DCO certification.